<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
	<meta http-equiv="content-type" content="xhtml+xml; charset=utf-8"/>
	<title>Über FxIF</title>
</head>
<body>
<h1>Um was geht’s?</h1>
<p>FxIF (Firefox exIF) erlaubt es Ihnen, in JPEG-Bildern enthaltene Metainformationen bequem in Firefox (oder SeaMonkey oder anderen kompatiblen Browsern) anzeigen zu lassen. Die meisten Digitalkameras speichern EXIF-Daten in allen Bildern die sie machen und viele Bearbeitungsprogramme fügen diese hinzu oder erlauben Ihnen Informationen zum Bild oder sich, dem Fotografen, hinzuzufügen.</p>

<p>FxIF ist in JavaScript und XUL geschrieben und sollte als solches portabel sein und auf jeder Plattform laufen auf der Mozilla läuft.</p>

<h1>Nutzung</h1>
<p>Machen Sie nach der Installation von FxIF einfach einen Rechtsklick auf ein Bild und wählen Sie dann <code>FxIF-Daten</code>. Die Metadaten werden in einem eigenen Fenster eingeblendet.<br/>
Sollte  die <a href="https://addons.mozilla.org/de/firefox/addon/14228" target="_blank">Element-properties</a>-Erweiterung installiert sein, die den bis Firefox-Version 3.6 vorhandenen Eigenschaften-Dialog nachrüstet, integriert sich FxIF dort.</p>

<h1>Geht was nicht?</h1>
<p>Ich möchte meine Erweiterung genauso gerne auf Ihrem System laufen lassen wie Sie. Aber manchmal funktioniert FxIF nicht bei Ihnen und um dies zu ändern benötige ich Ihre Hilfe.</p>
<p>Dazu bevorzuge ich die Kontaktaufnahme per e-Mail. Dabei ist folgendes sehr hilfreich: Wo genau liegt das Problem (kein Kontextmenü? Kein Eigenschaften-Dialog? Keine Daten? Fehlermeldung?), welche anderen Erweiterungen sind installiert, Screenshots des Fehlers, Ausgabe der Fehlerkonsole und Bild (bzw. URL) des Bildes bei dem das Problem auftritt.</p>

<h1>Im Detail</h1>
<h2>Was kann angezeigt werden?</h2>
<p>In JPEG-Dateien enthaltene Metadaten in drei Formen:</p>
<ul>
	<li>Binäre EXIF-Daten. Diese werden von fast allen Kameras automatisch geschrieben und enthalten technische Informationen über das Kameramodel und dessen Hersteller, Datum und Uhrzeit der Aufnahme, die verwendeten Blendenwerte und Verschlußzeiten, Brennweite und vieles mehr.</li>
	<li>IPTC-NAA-Daten in binärer Struktur (IIM). IPTC-NAA umfassen einen standardisierten Satz von Feldern die sich mit Informationen wie den Namen des Fotografen, Kurzbeschreibung der Aufnahme und Titel des Bildes, Copyright-Angaben, Schlagworte usw. befassen.</li>
	<li>XMP (Extensible Metadata Platform). Im Gegensatz zu den vorgenannten werden diese Daten nicht binär gespeichert sondern als im Bild enthaltenes XML-Dokument und sind nicht auf Kamera- oder Bildinformationen beschränkt sondern können beides und vieles mehr enthalten. Das Format wurde von Adobe entwickelt und fand zuerst vor allem durch deren Anwendungen wie Photoshop Verbreitung, findet mittlerweilen jedoch breite Unterstützung. Wie gesagt kann das XMP-Dokument sowohl alle vorgenannten EXIF- und IPTC-Daten enthalten wie auch weitere anwendungsspezifische.<br/>
  Ein großer Vorteil ist die Verwendung der UTF-8-Kodierung &ndash; so können Daten in jeder bekannten Sprache abgelegt werden. Es besteht sogar die Möglichkeit Informationen in mehreren Sprachen gleichzeitig zu enthalten und je nach Sprache des Anwenders die entsprechende auszulesen.</li>
</ul>
<p>Direkt aus der Kamera werden die meisten Bilder momentan nur binäre EXIF-Daten enthalten, dies wird sich in der Zukunft aber wahrscheinlich ändern und es existiert eine Vielzahl von Programmen um weitere Daten in allen Formaten hinzuzufügen. Software wie Photoshop kopiert die enthaltenen EXIF-Informationen beim Speichern in ein XMP-Dokument und fügt auch weitere zu sich selbst hinzu &ndash; zumindest wenn Sie nicht als <em>Für Web und Geräte speichern</em> verwenden.</p>

<h2>Und welche Felder genau?</h2>
<p>Im Detail können Sie die folgenden EXIF-Felder ansehen: ImageDescription, Make, Model, LensInfo, LensMake, LensModel, Orientation, ModifyDate/DateTimeOriginal/DateTimeDigitized, Artist, Copyright, Software, ExposureTime., FNumber, ExposureProgram, GPSInfo, ISO, ShutterSpeedValue, ExposureCompensation, MaxApertureValue, SubjectDistance, MeteringMode, LightSource, Flash, FocalLength, UserComment, ExifImageWidth, ExifImageLength, FocalPlaneXResolution, FocalPlaneResolutionUnit. ExposureMode, WhiteBalance, DigitalZoomRatio, FocalLengthIn35mmFormat, ColorSpace</p>
<p>Die folgenden Felder werden aus IPTC-NAA ausgelesen: By-line, Caption-Abstract, Headline, Instructions, CopyrightNotice, City, Sublocation, Province/State and Country</p>
<p>Und die folgenden aus XMP: dc:Creator, photoshop:Headline, dc:title, dc:description, dc:rights, xmpRights:UsageTerms, cc:license, photoshop:City, Iptc4xmpCore:Location, photoshop:State, photoshop:Country, tiff:Make, tiff:Model, aux:Lens, exif:DateTimeOriginal, exif:DateTimeDigitized, exif:FNumber, exif:ApertureValue, exif:FocalLength, exif:FocalLengthIn35mmFilm, exif:SubjectDistance, exif:ExposureTime, exif:Flash, tiff:Orientation, exif:ExposureBiasValue, exif:WhiteBalance, exif:LightSource, exif:MeteringMode, exif:ExposureProgram, exif:ExposureIndex, exif:ExposureMode, exif:ISOSpeedRatings, exif:DigitalZoomRatio, exif:GPSAltitude, exif:GPSAltitudeRef, exif:GPSLatitude, exif:GPSLongitude, exif:GPSImgDirection, exif:GPSImgDirectionRef, exif:ColorSpace, photoshop:ICCProfile, photoshop:Instructions, xap:CreatorTool, softwareAgent in mm:History</p>
<p>Ausserdem wird der JFIF-Kommentar ausgewertet.</p>
<p>Wie gesagt werden nicht alle Daten immer und auf einmal angezeigt. Denn zuerst einmal enthalten nicht alle Dateien alle Felder. Und zweitens sind manche Felder in verschiedenen Strukturen gleichbedeutend wie beispielsweise der Name des Fotografen oder die Bildbeschreibung, in diesen Fällen wird die Information nur einmal angezeigt. Die Priorität liegt hierbei auf XMP, dann folgt IPTC-NAA und schließlich EXIF.</p>
<p>Zu Ihrer Bequemlichkeit wird aus in EXIF-Feldern enthaltenen GPS-Koordinaten auch ein Weblink zu einem Kartenanbieter generiert und in der gleichen Zeile angezeigt. Dies gilt zumindest für Firefox 3 und SeaMonkey 2 da frühere Versionen die verwendete Technik nicht unterstützen. Seien Sie sich jedoch bewusst, dass diese Koordinaten diejenigen der Kamera sind und nicht des fotografierten Objekts. Vor allem bei Telefotos kann die Abweichung erheblich sein.</p>

<h2>Das ist nicht viel, warum nicht mehr?</h2>
<p>Der Zweck von FxIF ist, die Informationen auszugeben welche die meisten Benutzer sehen möchten wenn sie ein Bild im Browser ansehen. Das ist eine Schnellübersicht zu welche Kamera mit welchen Einstellungen wurde benutzt, wo wurde das Bild gemacht und was stellt es dar.</p>
<p>Es existiert eine Vielzahl von Programmen und auch ein, zwei Browser-Erweiterungen die Ihnen alle möglichen Informationen die im Bild enthalten sind anzeigen. Meiner Ansicht nach ist deren Zweck jedoch ein anderer und ergibt innerhalb des Browsers nicht viel Sinn. Die Ausgabe aller Informationen kann einfach überwältigend sein und dazu führen dass die gesuchten Informationen schwer zu finden sind.</p>

<h2>Und warum nur in JPEG-Bildern?</h2>
<p>Dieses Bildformat ist bei weitem das am weitesten verbreitete und die Konzentration darauf hält die Erweiterung einigermaßen einfach.</p>

<h2>Wo kann die Erweiterung alles laufen?</h2>
<p>Wie schon erwähnt ist FxIF in JavaScript und XUL geschrieben, sollte zusammen mit dem GRE (Gecko Runtime Environment) also überall laufen wo das GRE läuft.</p>
<p>Von Haus aus ist diese Erweiterung lauffähig im Firefox-Browser von Version 0.10 aufwärts, der Mozilla Application Suite von Version 1.7 an und ihrem Nachfolger SeaMonkey ab Version 1.0.</p>

<h2>Was kostet FxIF?</h2>
<p>Nichts. Die Erweiterung ist freie Software nach der Definition der Free Software Foundation. Sie ist dreifach-lizenziert als MPL 1.1, GPL 2.0, LGPL 2.1 und enthält wie die meisten Erweiterungen für die Mozilla-Plattform den Quellcode im XPI selbst.</p>

<h1>Konfiguriere mich</h1>
<p>Da die Geschmäcker verschieden sind habe ich mich entschieden zwei Dinge in FxIF konfigurierbar zu machen. Die Konfiguration kann über den Konfigurationsdialog im Add-On-Manager (verfügbar in Firefox und SeaMonkey 2) oder über direkte Änderung des jeweiligen Prefs erfolgen.</p>
<p>Die erste Option betrifft die Auswahl des Formats für die Koordinatenanzeige. Dieses kann entweder Grad Minuten (DM), Grad Minute Sekunden (DMS) &ndash; z.&thinsp;B. 40&deg;&nbsp;43&prime;&nbsp;20.7&Prime;&nbsp;N, 74&deg;&nbsp;02&prime;&nbsp;47.2&Prime;&nbsp;W &ndash; oder Dezimalgrad (DD), z.&thinsp;B. 40.722417&deg;&nbsp;N, 74.046444&deg;&nbsp;W, sein. Die Angaben werden auf zwei Nachkommastellen in DM/DMS und sechs Nachkommastellen in DD gerundet. Das dazugehörige Pref ist <code>extensions.fxif.gpsFormat</code> wobei 0 DMS, 2 DM und 1 DD bedeutet.</p>
<p>Die andere Option betrifft den Kartenanbieter der für den Weblink verwendet wird. Der Default (wenn das Pref nicht gesetzt oder leer ist) ist <code>openstreetmap.org</code> zu verwenden, aber wie ich schon schrieb sind die Geschmäcker verschieden.</p>
<p>Um also den Kartenanbieter zu ändern geben Sie die URL in das Feld (oder das Pref) ein. Sie können wirklich jede URL eingeben. Um die jeweiligen Koordinaten zu verwenden muß jedoch ein <code>%lat%</code> überall dort wo der Breitengrad eingefügt werden soll stehen und <code>%lon%</code> überall wo der Längengrad eingefügt werden soll.</p>
<p>Der Default ist also</p>
<p><code>http://www.openstreetmap.org/?mlat=%lat%&amp;mlon=%lon%&amp;layers=M</code></p>
<p>aber wenn Sie Google als Kartenanbieter verwenden wollen, geben Sie beispielsweise folgendes ein:</p>
<p><code>http://maps.google.com/maps?ll=%lat%,%lon%&amp;q=%lat%,%lon%&amp;hl=%lang%</code></p>
<p>oder um Yahoo zu verwenden</p>
<p><code>http://de.maps.yahoo.com/#mvt=m&amp;lat=%lat%&amp;lon=%lon%</code></p>
<p>oder</p>
<p><code>http://atlas.mapquest.com/maps/map.adp?searchtype=address&amp;formtype=latlong&amp;latlongtype=decimal&amp;latitude=%lat%&amp;longitude=%lon%</code></p>
<p>für MapQuest usw. In der URL werden Breite und Länge jeweils ungerundet im Dezimalformat eingefügt.</p>
<p>Haben Sie das <code>%lang%</code> in der URL für Google Maps bemerkt? Dieses ist der dritte verfügbare Platzhalter und wird mit der Sprache ersetzt die Sie im Browser als bevorzugte Sprache für Webinhalte angegeben haben. Die Setzung dieses Parameters ist nicht nötig, aber zumindest im Falle von Google wird dann die jeweilige Seite in der Sprache des Nutzers angezeigt.</p>
<p>Ebenso können Sie im Falle von Google den Parameter „z=“ oder im Falle von OpenStreetMap und Yahoo! den Parameter „zoom=“ hinzufügen falls Ihnen die Standardzoomstufe des Providers nicht zusagt. Einfach hinter das Gleichzeichen eine Zoomstufe eintragen (interessante Zoomstufen dürften um 15 herum liegen).</p>
<p>Das zugehörige Pref ist <code>extensions.fxif.mapProvider</code>.</p>

<h1>Gibt es lokalisierte Versionen?</h1>
<p>FxIF ist bereits verfügbar in brasilianischem Portugiesisch, vereinfachtem Chinesisch, Deutsch, Englisch, Finnisch, Französisch, Italienisch, Japanisch, Niederländisch, Polnisch, Russisch, Schwedisch, Spanisch und Tschechisch. Die jeweils verwendete hängt von der Sprache des Browsers ab.</p>
<p>Sollten Sie Ihre Sprache nicht in der Liste finden, sind Sie eingeladen eine Übersetzung dafür beizusteueren. Sie können die <a href="http://code.google.com/p/fxif/source/browse/trunk/locale/de">deutsche Version der .dtd- und .properties-Dateien</a> aus dem FxIF-Repository herunterladen und mir die übersetzte Version zumailen. Ebenso bin ich dankbar für Fehlerbehebungen in Übersetzungen.</p>
<p>FxIF hat auch eine Seite auf <a href="http://www.babelzilla.org/index.php?option=com_wts&extension=5292&type=show" target="_blank">BabelZilla.org</a> worüber die meisten Übersetzungen organisiert sind. Sie können also auch dort mitmachen.</p>

<h1>Ich habe einen Fehler gefunden</h1>
<p>Das kommt vor. Sie können <a href="mailto:ch.ey@gmx.net">mir</a> darüber eine Mail schreiben. Oder im <a href="http://code.google.com/p/fxif/issues/list" target="_blank">Google-Code-Projekt</a> den Fehler eintragen. Ich werde mich dann darum kümmern.</p>

<h1>Wann wird die nächste Version freigegeben?</h1>
<p>Wie bei den meisten Projekten „wenn sie fertig ist“. Seit 0.2.3 ist der Quellcode für FxIF <a href="http://code.google.com/p/fxif/">auf Google Code</a> zuhause und kann jederzeit <a href="http://code.google.com/p/fxif/source/checkout">über svn</a> ausgecheckt werden.</p>

<h1>Versionshistorie</h1>
<h2>Was ist neu in 0.30</h2>
<ul>
	<li>Anzeige von GPS-Koordinaten</li>
	<li>Dekodierung von binären IPTC-NAA- und XMP-Daten</li>
	<li>Dekodierung von Ersteller, Titel, Beschreibung und Copyright</li>
	<li>Fähigkeit mit Bildern zu arbeiten die aus POP-Mailboxen, von News- und IMAP-Servern geöffnet wurden (im Falle von SeaMonkey)</li>
  <li>Funktioniert auch mit Firefox >= 3 und SeaMonkey >= 2</li>
  <li>Funktioniert auch mit Bildern die nicht gecached wurden.</li>
</ul>
<h2>Was ist neu in 0.3.1</h2>
<ul>
	<li>Funktioniert auch mit Firefox >= 3.6 mit dessen Einführung der Bildeigenschaften-Dialog entfernt wurde.</li>
</ul>
<h2>Was ist neu in 0.3.2</h2>
<ul>
	<li>Ein paar Bugfixes, darunter auch das Verschwinden aller Toolbars wenn die Druckvorschau geschlossen wird.</li>
</ul>
<h2>Was ist neu in 0.4</h2>
<ul>
	<li>Auch EXIF-Daten die im XMP-Format statt im binären Format vorliegen, können jetzt ausgewertet werden. Auch werden jetzt ein paar mehr Felder ausgewertet, vor allem solche zum Ort der Aufnahme. Intern werden jetzt mehr Felder berücksichtigt um die Lizenzangaben zu füllen.</li>
	<li>Die Reihenfolge der Felder in der Anzeige wurde geändert, ein paar Bugs im XMP-Interpreter und dem Leser für binäre EXIF-Daten behoben.</li>
	<li>Das eigene EXIF-Fenster kann nun mittels ESC geschlossen werden und der Kopieren-Button hat jetzt einen Shorcut (Alt+C, Option+C am Mac).</li>
	<li>Auch Bilder die komprimiert (z.B. mit "Content-Encoding: gzip") ausgeliefert werden, können gelesen werden.</li>
	<li>FxIF arbeitet nun mit Geoff Lankows <a href="https://addons.mozilla.org/de/firefox/addon/14228" target="_blank">Element-properties</a>-Erweiterung zusammen und kann sich dort einhängen um wie in Firefox < 3.6 zu erscheinen.</li>
	<li>Neue Übersetzung ins Russische durch Max Pozdeev. Alle Lokalisierungen wurden überholt, danke hierfür an die alten und neuen Übersetzer auf <a href="http://www.babelzilla.org" target="_blank">BabelZilla</a>.</li>
</ul>
<h2>Was ist neu in 0.4.1</h2>
<ul>
	<li>DateTime wird nur noch benutzt wenn DateTimeOriginal und DateTimeDigitized nicht vorhanden sind.</li>
	<li><a href="http://code.google.com/p/fxif/issues/detail?id=3" target="_blank">Issue 3</a> behoben: Die Erkennung des XMP-Datenblocks wurde etwas gelockert um einen Bug in mancher Grafiksoftware zu umgehen.</li>
	<li>Nicht existierende Informationen zum Blitzeinsatz in den XMP-Daten führen jetzt nicht mehr zum Fehlschlagen der XMP-Auswertung.</li>
	<li>Allgemein führt ein Problem in der Auswertung eines Datenblocks jetzt nicht mehr dazu dass überhaupt keine Daten mehr angezeigt werden. Stattdessen werden die bis zum Fehler gelesenen Daten des jeweiligen Blocks angezeigt und ein Hinweis auf einen Fehler und möglicherweise fehlende Daten eingeblendet.</li>
	<li><a href="http://code.google.com/p/fxif/issues/detail?id=2" target="_blank">Issue 2</a> behoben: ein Bug durch den "chr" als Sprache genutzt wurde wenn das Pref intl.accept_language auf Default für den jeweiligen Browser gelassen wurde. (Danke an Hector Zhao)</li>
	<li>Neue Übersetzung für Niederländisch, danke dafür an markh van BabelZilla.org.</li>
</ul>
<h2>Was ist neu in 0.4.2</h2>
<ul>
	<li>Blitzdaten in XMP werden nun besser ausgewertet (nun auch in Child-Tags des Flash-Tags statt nur in seinen Attributen). Danke an Phil Lattimore für die Rückmeldung.</li>
  <li>Zumindest eine Software hängt ein Nullbyte and das XMP-Dokument an und der Mozilla-XML-Parser mag das überhaupt nicht. Ich habe einen Workaround für diesen Fall eingefügt der das Dokument um ein Byte kürzt.</li>
</ul>
<h2>Was ist neu in 0.4.3</h2>
<ul>
	<li>An ein paar Stellen war ich zu optimistisch bezüglich der Anzahl Bytes in einem JPEG-Marker. Das konnte dazu führen dass ich eine negative Anzahl Bytes lesen wollte was Mozillas Streamreader nicht so sehr gefiel. Danke an Jemini für die Meldung.</li>
	<li>Behebung eines Bugs der dazu führte das der vorgenannte Abbruch dem Benutzer nicht sauber gemeldet wurde.</li>
  <li><a href="http://code.google.com/p/fxif/issues/detail?id=4" target="_blank">Issue 4</a> behoben: Der Button „Kopieren“ kopiert keine GPS-Koordinaten.</li>
  <li><a href="http://code.google.com/p/fxif/issues/detail?id=5" target="_blank">Issue 5</a> behoben: Enthielt das EXIF-Tag Orientation einen unbekannten Wert, brach FxIF ab.</li>
  <li><a href="http://code.google.com/p/fxif/issues/detail?id=6" target="_blank">Issue 6</a> behoben: Daten aus dem binären EXIF-Block wurden einfach kopiert und enthalten per Konvention Doppelpunkte als Trenner. Diese werden nun durch Bindestriche ersetzt um der Formatierung von Daten aus IPTC und XMP zu entsprechen (JJJJ-MM-TT wie in ISO 8601 empfohlen).</li>
  <li>Außerdem enthalten Daten im binären EXIF-Block keine Zeitzoneninformationen. Dies wird nun bei der Ausgabe erwähnt.</li>
  <li><a href="http://code.google.com/p/fxif/issues/detail?id=8" target="_blank">Issue 8</a> behoben: Unterstützung für die Formatierung von GPS-Position als Grad und Minuten.</li>
  <li>Die Auswertung der Blitzinformationen und Stringgenerierung wurde auf Basis eines Patches von Max Pozdeev überarbeitet.</li>
  <li>Neue Übersetzungen ins Schwedische durch Jan Kardell (über BabelZilla.org) und ins Finnische durch Ilari Oras (was <a href="http://code.google.com/p/fxif/issues/detail?id=9" target="_blank">Issue 9</a> behebt).</li>
  <li>Die polnische Übersetzung ist leider nicht enthalten da zwei neue Strings nicht übersetzt wurden.</li>
  <li><a href="http://code.google.com/p/fxif/issues/detail?id=10" target="_blank">Issue 10</a> behoben: Endlose Rekursionen wenn der Exif Interoperability Offset oder Exif Offset auf den eigenen Startoffset zeigen. Das ist ein Fehler in den Daten.</li>
</ul>
<h2>Was ist neu in 0.4.4</h2>
<ul>
  <li>Auslesen der Informationen zum Objektiv (in binärem Exif, aus XMP-Daten wurde schon länger ausgelesen) und verwendeten Software.</li>
	<li>Wegfall der Unterstützung für die alte Mozilla Suite. Sie ist schon lange genug tot und sollte zur eigenen Sicherheit sowieso nicht mehr verwendet werden.</li>
  <li>Zumindest seit Gecko 2 (Firefox 4, SeaMonkey 2.1) ist der XML-Parser sehr pingelig wenn ihm nicht korrekt als UTF-8 oder Unicode codierte Dokumente übergeben werden. Manche Bilder enthalten jedoch gegen die XMP- (und eigentlich auch XML-) Spezifikation verstoßende Dokumente mit z.B. ISO-8859-1-Umlauten. Ich habe einen Workaround eingefügt der bei Fehler beim Parsen einen zweiten Versuch macht in dem die Sonderzeichen zuerst konvertiert werden. Das kann zu falsch dargestellten Sonderzeichen in solchen Dateien führen, aber immerhin sind die Dokumente so überhaupt lesbar.</li>
  <li>Strg+W, bzw. Befehl+W schließt nun (wie seit Version 0.4 schon Escape) das FxIF-eigene Fenster.</li>
  <li>Das FxIF-eigene Fenster verhält sich jetzt genauso wie wenn die Daten in das Browser-eigene Eigenschaften-Fenster (bzw. das der <a href="https://addons.mozilla.org/de/firefox/addon/14228" target="_blank">Element-properties</a>-Erweiterung) eingeblendet werden. Das heißt es ist nun möglich mehrere parallel zu öffnen statt daß eines immer wiederverwendet wird.</li>
  <li>Verbessertes handling von IPTC-Datum: Wenn IPTC nur entweder Datum oder Zeit enthält wird es nur benutzt wenn nicht schon ein Datum gesetzt ist.</li>
  <li>Jetzt werden auch JFIF-Kommentare angezeigt.</li>
  <li>Neue Übersetzung ins Türkische, Danke an omrakin auf <a href="http://www.babelzilla.org" target="_blank">BabelZilla</a>, und die polnische Übersetzung ist wieder enthalten.</li>
</ul>
<h2>Was ist neu in 0.4.5</h2>
<ul>
	<li>Bug behoben welcher verursachte dass der Browser sich hart aufhing. Danke an Radek Docekal für die Meldung.</li>
  <li>Bug behoben der ein FxIF-Daten-Fenster mit allen Bezeichnern aber ohne Daten zeigte. Dieses wurde durch Bilder die eine <map> verwenden sichtbar. Danke an Joop Nijenhuis für die Meldung.</li>
  <li>Wenn das mapProvider-Pref nicht gesetzt ist, wurde ein Default genutzt jedoch nicht ins entsprechende Eingabefeld in den Optionen eingefüllt. Das wird nun gemacht.</li>
  <li>Für die Angabe der zur Erstellung verwendeten Software wurde auch das XMP-Feld CreatorTool ausgewertet und eine eventuelle Angabe aus dem EXIF-Feld Software überschrieben. CreatorTool jedoch enthält (zumindest laut Spezifikation) nur die ursprüngliche Software, nicht die zuletzt für die Erstellung des vorliegenden Bildes verwendete (wie es beim EXIF-Feld Software sein sollte).<br />
Deshalb wird nun auch das Feld softwareAgent (in der History-Liste) ausgewertet und letzte dort vorhandene Listeneintrag angezeigt. Das Feld CreatorTool wird nur verwendet sollte das EXIF-Feld Software nicht vorhanden sein.</li>
  <li>Es werden nun mehr Objektivinfos aus den Canon-Maker-Notes ausgelesen.</li>
</ul>
<h2>Was ist neu in 0.4.6</h2>
<ul>
  <li>Einen Fehler beim Interpretieren von Canon Maker Notes behoben. FxIF hatte dabei das Byteordering der EXIF-Felder verwendet, Canon Maker Notes sind jedoch unabhängig davon anscheinend immer in Intel Byte Order (Little Endian).</li>
  <li>Einen weiteren Fehler beim Interpretieren von Canon Maker Notes behoben. Es gibt anscheinend Software die die Maker Notes innerhalb der Datei verschiebt, die Zeiger dorthin auch anpasst, aber die Offsets innerhalb der Maker Notes nicht. Deshalb wird nun ein Korrekturoffset aus dem Maker-Notes-Footer errechnet. Danke an Phil Harveys Image-Exif-Tools für diese Einsicht.</li>
  <li>Von FxIF genutzte Einstellungen stehen nun auf der Sync-Whitelist. Das bedeutet, dass FxIF-Options nun per <a href="https://support.mozilla.org/de/kb/was-ist-firefox-sync" target="_blank">Firefox-Sync</a> synchronisiert werden.</li>
  <li>FxIF stoppt nun beim Lesen von Strings wenn es ein Nullbyte erreicht. Bisher wurden sie einfach übergangen wenn mehr Bytes für ein Feld angegeben waren. Danke an Dennis van den Broek für das Testbild um den Bug aufzudecken.</li>
  <li>FxIF nterpretiert nun die Angabe der Richtung in die die Kamera während der Aufnahme zeigte wenn diese Information aufgezeichnet wurde. Danke an Dennis van den Broek für die Testbilder.</li>
  <li><a href="http://code.google.com/p/fxif/issues/detail?id=18" target="_blank">Issue 18</a> behoben: Eine schlechte Regex umgeschrieben die in zu vielen Fällen zutraf.</li>
</ul>
<h2>Was ist neu in 0.4.7</h2>
<ul>
  <li><a href="http://code.google.com/p/fxif/issues/detail?id=19" target="_blank">Issue 19</a> "behoben": Warnung an den Benutzer bei Parserfehlern des XMP-Dokumentes deaktiviert. Es gibt keinen mir bekannten Workaround für solche Fehler solange FxIF Mozillas DOM Parser verwendet. Und ich habe nicht vor einen eigenen mitzubringen.</li>
  <li>Eine Exception trat auf wenn das Feld GpsImgRef in EXIF oder XMP leer war oder etwas anderes als M oder T darin stand.</li>
  <li><a href="http://code.google.com/p/fxif/issues/detail?id=17" target="_blank">Issue 17</a> behoben: Endlose Rekursionen wenn der Exif Interoperability Offset oder Exif Offset auf ein Verzeichnis zeigt das bereits verarbeitet wurde. Dies ist ähnlich dem, jedoch komplexer als Issue 10 der in FxIF 0.4.3 behoben wurde.</li>
  <li>Einen Fehler behoben der bewirkte dass die Daten zum Urheber (bisher Photograph) nicht mehr ausgegeben wurden. Hier hatte ich die zuständige Variable nur an einer statt allen Stellen umbenannt. Vielen Dank an Oliver Theobald fürs Finden.</li>
  <li>In mindestens einem Bild wurde der ISO-Wert nicht wie spezifiziert als Integer sondern als String abgelegt. FxIF ging deshalb von Integer aus, fiel auf die Nase und die restlichen Daten wurden nicht ausgelesen. Für dieses und ein weiteres Feld für das sich dieser Fehler auch auswirken könnte habe ich deshalb einen Workaround eingebaut. Vielen Dank an Aaron Gullison fürs Finden.</li>
  <li>Die Auswertung der EXIF-Felder Aperture und MaxAperture war fehlerhaft – und zwar mindestens seit Version 0.2.3. Ich vermute einen Fehler bei der Portierung des Codes vom (in C geschriebenen) Jhead. Anders als beim Feld FNumber wird der Wert nicht direkt übernommen sondern einer Formel unterworfen – ich kann nicht behaupten diese bzw. deren Grund zu verstehen, aber richtig portiert kommt nun jedenfalls das erwartete Ergebnis heraus. Vielen Dank an Babar de Saint Cyr fürs Finden.</li>
  <li>Das EXIF-Feld UserComment bietet laut Spezifikation die Möglichkeit den String in ASCI, JIS, UNICODE und selbstdefinierter Kodierung abzulegen. Bisher hatte FxIF einfach alles als ASCII interpretiert und bei anderer Kodierung nur den Kodierungsnamen angezeigt. Nun wird ASCII und UNICODE verstanden. Bei anderen Kodierungen wird der Inhalt als ASCII-String angezeigt. Vielen Dank an Babar de Saint Cyr fürs Finden. Dieser Fehler wurde auch als <a href="http://code.google.com/p/fxif/issues/detail?id=20" target="_blank">Issue 20</a> gemeldet.</li>
  <li>Neue Übersetzung ins Ungarische, Danke an Szilárd Andai.</li>
</ul>
<h2>Was ist neu in 0.4.7.1</h2>
<ul>
  <li>Code von der nächsten noch in der Entwicklung befindlichen Version rutschte leider in den Build hinein und blies den Seiteninformationen-Dialog auf. Dieser Code wurde wieder entfernt. Dieser Fehler wurde auch als <a href="http://code.google.com/p/fxif/issues/detail?id=21" target="_blank">Issue 21</a> gemeldet.</li>
</ul>
<h2>Was ist neu in 0.4.8</h2>
<ul>
  <li>Manches Stück Software lässt leider einfach den Pascal-String aus dem 8BIM-Header der binären IPTC-Daten weg. Dadurch verschieben sich alle IPTC-Daten und bringt manchen Decoder durcheinander (auch das phantastische exiftool). FxIF verfügt nun um eine zusätzliche Plausibilitätsprüfung und einen Mechanismus um den Fehler zu umgehen. Vielen Dank an Oleg V. Samsonov fürs Melden.</li>
  <li>Es gibt Bilder die für Verzweigungen zu EXIF-Unterverzeichnissen ungültige Offsets enthalten. Im mir vorliegenden Fall nur zu Offset 0, aber andere sind auch möglich. Ich habe deshalb nun an mehreren Stellen verschiedene Prüfungen gegen so etwas eingefügt. Vielen Dank an Alice Cheung fürs Melden.</li>
  <li>Manche Bilder enthalten EXIF-Kommentare die nur aus Nullbytes bestehen. Diese wurden leider auch als solche angezeigt. Dabei hatte ich doch in Version 0.4.6 die Vorgehensweise beim Umgang mit Nullbytes in Strings geändert. Nur hatte ich für einen anderen Fix in der gleichen Version eine zusätzliche Dekodierfunktion mit dem alten Verhalten einbauen müssen und an einer Stelle fälschlicherweise diese statt der alten verwendet. Jetzt wird auch dort die richtige Version verwendet. Danke wieder an Dennis van den Broek für den Report.</li>
  <li>Zumindest ein Programm schreibt in die EXIF-Angaben im XMP-Format nicht wie spezifiziert, sondern ausgeschrieben. So beispielsweise für exif:FNumber nicht „35/10“ sondern „f/3,5“, für  exif:ExposureProgram gar „Zeitautomatik“ statt „4“. FxIF überprüft nun ob der Wert im richtigen Format ist. Falls nicht, wird der Wert nicht interpretiert, sondern 1:1 übernommen. Das aber nur, wenn die Eigenschaft nicht bereits befüllt wurde, beispielsweise über binäre EXIF-Eigenschaften. Vielen Dank an Heino Tiedemann fürs Melden und das Testbild.</li>
  <li>Obwohl das nicht so vorgesehen war, wurde der EXIF-Wert DigitalZoomRation nie angezeigt wenn er als XMP-Wert enthalten war. Nun wird er angezeigt sofern er größer als 1 ist.</li>
  <li>Eine Prüfung auf eine Arrayüberschreitung funktioniert zwar, brach jedoch das ganze Datenauslesen ab und meldete einen schweren Fehler. Da es keinen vernünftigen Workaround gibt, habe ich die Auswirkung nun abgemildert und der Wert der zur Überschreitung führen würde wird nun einfach überlesen. Vielen Dank an Heino Tiedemann fürs Melden und das Testbild.</li>
  <li>Ich habe einen Workaround entfernt der eine “Seltsame Codierung in einigen älteren Kameras behebt.” und der ISO-Werte unter 50 mit 200 multipliziert. Dieses Verhalten kommt aus dem Programm jhead auf dem FxIF basierte. Dieser Workaround wurde dort mit der Version 2.97 entfernt. Dieser Fehler wurde auch als <a href="http://code.google.com/p/fxif/issues/detail?id=22" target="_blank">Issue 22</a> gemeldet.</li>
  <li><a href="http://code.google.com/p/fxif/issues/detail?id=23" target="_blank">Issue 23</a> behoben: Für Bilder deren Erstellungszeit (Feld TimeCreated in den binären IPTC-Daten) keine Zeitzoneninformation enthält wurde überhaupt keine Zeit ausgegeben. Dies rührt daher, dass FxIF der Spezifikation genau folgte in der die Zeitzone als Pflichtangabe beschrieben ist. In der neuen Version ist diese Angabe nun optional. Ist sie nicht vorhanden, wird in der Ausgabe entsprechend darauf hingewiesen. Der gleiche Fall wurde auch bei den Zeitangaben in den XMP-Daten behoben.</li>
</ul>
<h2>Was ist neu in 0.4.9</h2>
<ul>
  <li>Wie mich Manfred Härtel richtigerweiße aufklärte, war die bisherhige Präzission der Anzeige von GPS-Koordinaten durch FxIF im Format Grad, Minuten weniger genau als in den anderen beiden Formaten (Grad und Grad, Minuten, Sekunden). FxIF zeigt deshalb seit dieser Version 4 Nachkommastellen an.</li>
  <li>Für Strings in binären EXIF-Daten ist keine Codierung spezifiziert, weshalb FxIF bisher EXIF-Strings 1:1 anzeigte. Inzwischen wird jedoch sogar von der MWG empfohlen, die Strings in UTF-8-Codierung dort abzulegen und manche Programme setzen dies beim Schreiben um. Dies führte dazu, dass frühere FxIF-Versionen in diesen Fällen statt Sonderzeichen nur wilde Zeichenkombinationen anzeigte. Dies wurde nun geändert indem FxIF davon ausgeht dass es sich um in UTF-8 codierte Strings handelt und nur dann auf direkte Anzeige zurückfällt wenn im String mindestens ein nicht-UTF-8-codiertes Sonderzeichen gefunden wird. Vielen Dank an Tobias Kühne für die Anregung und das Beispielbild.</li>
  <li>Ich wurde darauf aufmerksam gemacht, dass FxIF 0.4.8 bei von Lightroom 6/CC geschriebenen Bildern nur wenige Daten anzeigt. Grund war eine etwas überstrenge Sicherheitsabfrage die ich in Version 0.4.8 hinzugefügt hatte. Worüber diese Sicherheitsabfrage stolperte ist, dass in von Lightroom 6/CC geschriebenen Bildern, sich der Exif SubIFD <strong>vor</strong> dem IFD0 befindet. Das ist ungewöhnlich, aber vollkommen in Ordnung. Ich habe die Abfrage daher etwas gelockert und die Anzeige funktioniert wieder wie früher. Vielen Dank für die Meldung an Fred Hönig und Toshik für die Meldung und ein Testbild.</li>
</ul>
<h2>Was ist neu in 0.5</h2>
<ul>
	<li>Unterstützung für Maker Notes. Maker Notes sind einfach umständlich und das Format im binären Exif einfach hässlich zu implementieren da die Formate der einzelnen Information nicht nur zwischen Herstellern sondern auch Kameramodellen variieren. So benötigen die nun unterstützen Objektivkennungen für Canon, Nikon, Pentax and Sony x Variationen. Ebenfalls werden diese Objektivbezeichnungen nicht einfach in die Bilddatei geschrieben, sondern es wird nur eine Zahl hinterlegt. Programme wie FxIF müssen sich auf die Arbeit vieler Freiwilliger stützen die Testbilder zur Verfügung stellen da die Zahlencodes nirgends offiziell dokumentiert sind. Es ist auch zu beachten, dass nicht jedes Kameramodel diese Informationen hinterlegen.</li>
	<li>Neue Übersetzungen ins Ukrainische, Danke an Yaroslav Krytsun auf <a href="http://www.babelzilla.org" target="_blank">BabelZilla</a> und traditionelles Chinesisch, Danke an Rock Yang.</li>
</ul>
</body>
</html>